محدودسازی نرخ درخواست API: پیاده‌سازی الگوریتم سطل توکن

در دنیای متصل امروزی، APIها (رابط‌های برنامه‌نویسی کاربردی) ستون فقرات تعداد بی‌شماری از برنامه‌ها و سرویس‌ها هستند. آن‌ها به سیستم‌های نرم‌افزاری مختلف امکان می‌دهند تا به طور یکپارچه با یکدیگر ارتباط برقرار کرده و داده‌ها را تبادل کنند. با این حال، محبوبیت و دسترسی‌پذیری APIها آن‌ها را در معرض سوءاستفاده و بار اضافی بالقوه نیز قرار می‌دهد. بدون اقدامات حفاظتی مناسب، APIها می‌توانند در برابر حملات محروم‌سازی از سرویس (DoS)، اتمام منابع و تخریب کلی عملکرد آسیب‌پذیر شوند. اینجاست که محدودسازی نرخ درخواست API وارد عمل می‌شود.

محدودسازی نرخ درخواست یک تکنیک حیاتی برای محافظت از APIها از طریق کنترل تعداد درخواست‌هایی است که یک کلاینت می‌تواند در یک دوره زمانی مشخص ارسال کند. این کار به تضمین استفاده منصفانه، جلوگیری از سوءاستفاده و حفظ پایداری و در دسترس بودن API برای همه کاربران کمک می‌کند. الگوریتم‌های مختلفی برای پیاده‌سازی محدودسازی نرخ درخواست وجود دارد، و یکی از محبوب‌ترین و مؤثرترین آن‌ها الگوریتم سطل توکن (Token Bucket) است.

الگوریتم سطل توکن چیست؟

الگوریتم سطل توکن یک الگوریتم از نظر مفهومی ساده اما قدرتمند برای محدودسازی نرخ درخواست است. یک سطل را تصور کنید که می‌تواند تعداد مشخصی توکن را در خود نگه دارد. توکن‌ها با نرخ از پیش تعریف‌شده‌ای به سطل اضافه می‌شوند. هر درخواست API ورودی یک توکن از سطل مصرف می‌کند. اگر سطل توکن‌های کافی داشته باشد، به درخواست اجازه عبور داده می‌شود. اگر سطل خالی باشد (یعنی توکنی در دسترس نباشد)، درخواست یا رد می‌شود یا تا زمانی که توکنی در دسترس قرار گیرد در صف قرار می‌گیرد.

در ادامه، اجزای کلیدی آن شرح داده شده است:

• اندازه سطل (ظرفیت): حداکثر تعداد توکن‌هایی که سطل می‌تواند در خود نگه دارد. این نشان‌دهنده ظرفیت انفجاری (burst capacity) است – یعنی توانایی مدیریت یک موج ناگهانی از درخواست‌ها.
• نرخ پر شدن مجدد توکن: نرخی که توکن‌ها به سطل اضافه می‌شوند، که معمولاً بر حسب توکن در ثانیه یا توکن در دقیقه اندازه‌گیری می‌شود. این نرخ، حد متوسط نرخ درخواست را تعریف می‌کند.
• درخواست: یک درخواست API ورودی.

نحوه کارکرد:

1. هنگامی که درخواستی می‌رسد، الگوریتم بررسی می‌کند که آیا توکنی در سطل وجود دارد یا خیر.
2. اگر سطل حداقل یک توکن داشته باشد، الگوریتم یک توکن را حذف کرده و به درخواست اجازه عبور می‌دهد.
3. اگر سطل خالی باشد، الگوریتم درخواست را رد کرده یا در صف قرار می‌دهد.
4. توکن‌ها با نرخ پر شدن مجدد از پیش تعریف‌شده، تا سقف ظرفیت سطل، به آن اضافه می‌شوند.

چرا الگوریتم سطل توکن را انتخاب کنیم؟

الگوریتم سطل توکن مزایای متعددی نسبت به سایر تکنیک‌های محدودسازی نرخ درخواست، مانند شمارنده‌های پنجره ثابت یا شمارنده‌های پنجره لغزان، ارائه می‌دهد:

• ظرفیت انفجاری: این الگوریتم امکان ارسال موجی از درخواست‌ها تا سقف اندازه سطل را فراهم می‌کند و الگوهای استفاده قانونی را که ممکن است شامل افزایش‌های ناگهانی ترافیک باشند، در نظر می‌گیرد.
• محدودسازی نرخ روان: نرخ پر شدن مجدد تضمین می‌کند که نرخ متوسط درخواست در محدوده تعریف‌شده باقی می‌ماند و از بارگذاری بیش از حد مداوم جلوگیری می‌کند.
• قابلیت پیکربندی: اندازه سطل و نرخ پر شدن مجدد را می‌توان به راحتی برای تنظیم دقیق رفتار محدودسازی نرخ برای APIهای مختلف یا سطوح کاربری متفاوت تنظیم کرد.
• سادگی: این الگوریتم برای درک و پیاده‌سازی نسبتاً ساده است و آن را به یک انتخاب عملی برای بسیاری از سناریوها تبدیل می‌کند.
• انعطاف‌پذیری: می‌توان آن را برای موارد استفاده مختلف، از جمله محدودسازی نرخ بر اساس آدرس IP، شناسه کاربر، کلید API یا معیارهای دیگر، تطبیق داد.

جزئیات پیاده‌سازی

پیاده‌سازی الگوریتم سطل توکن شامل مدیریت وضعیت سطل (تعداد فعلی توکن‌ها و آخرین برچسب زمانی به‌روزرسانی) و اعمال منطق برای مدیریت درخواست‌های ورودی است. در ادامه یک طرح کلی مفهومی از مراحل پیاده‌سازی ارائه شده است:

1. مقداردهی اولیه:
   • یک ساختار داده برای نمایش سطل ایجاد کنید که معمولاً شامل موارد زیر است:
   • `tokens`: تعداد فعلی توکن‌ها در سطل (با اندازه سطل مقداردهی اولیه می‌شود).
   • `last_refill`: برچسب زمانی آخرین باری که سطل مجدداً پر شده است.
   • `bucket_size`: حداکثر تعداد توکن‌هایی که سطل می‌تواند در خود نگه دارد.
   • `refill_rate`: نرخی که توکن‌ها به سطل اضافه می‌شوند (مثلاً توکن در ثانیه).
2. مدیریت درخواست:
   • هنگامی که درخواستی می‌رسد، سطل مربوط به کلاینت را بازیابی کنید (مثلاً بر اساس آدرس IP یا کلید API). اگر سطل وجود نداشت، یک سطل جدید ایجاد کنید.
   • تعداد توکن‌هایی که از آخرین بار پر شدن باید به سطل اضافه شوند را محاسبه کنید:
   • `time_elapsed = current_time - last_refill`
   • `tokens_to_add = time_elapsed * refill_rate`
   • سطل را به‌روزرسانی کنید:
   • `tokens = min(bucket_size, tokens + tokens_to_add)` (اطمینان حاصل کنید که تعداد توکن‌ها از اندازه سطل بیشتر نشود)
   • `last_refill = current_time`
   • بررسی کنید که آیا توکن‌های کافی در سطل برای پاسخ به درخواست وجود دارد یا خیر:
   • اگر `tokens >= 1`:
     • تعداد توکن‌ها را کاهش دهید: `tokens = tokens - 1`
     • به درخواست اجازه عبور دهید.
   • در غیر این صورت (اگر `tokens < 1`):
     • درخواست را رد یا در صف قرار دهید.
     • یک خطای عبور از حد مجاز نرخ (مثلاً کد وضعیت HTTP 429 Too Many Requests) بازگردانید.
   • وضعیت به‌روزشده سطل را ذخیره کنید (مثلاً در یک پایگاه داده یا حافظه پنهان).

مثال پیاده‌سازی (مفهومی)

در ادامه یک مثال ساده و مفهومی (غیر وابسته به زبان خاص) برای نشان دادن مراحل کلیدی ارائه شده است:

class TokenBucket:
    def __init__(self, bucket_size, refill_rate):
        self.bucket_size = bucket_size
        self.refill_rate = refill_rate  # tokens per second
        self.tokens = bucket_size
        self.last_refill = time.time()

    def consume(self, tokens_to_consume=1):
        self._refill()
        if self.tokens >= tokens_to_consume:
            self.tokens -= tokens_to_consume
            return True  # Request allowed
        else:
            return False # Request rejected (rate limit exceeded)

    def _refill(self):
        now = time.time()
        time_elapsed = now - self.last_refill
        tokens_to_add = time_elapsed * self.refill_rate
        self.tokens = min(self.bucket_size, self.tokens + tokens_to_add)
        self.last_refill = now

# Example usage:
bucket = TokenBucket(bucket_size=10, refill_rate=2)  # Bucket of 10, refills at 2 tokens per second

if bucket.consume():
    # Process the request
    print("Request allowed")
else:
    # Rate limit exceeded
    print("Rate limit exceeded")

توجه: این یک مثال پایه است. یک پیاده‌سازی آماده برای محیط عملیاتی نیازمند مدیریت همزمانی، پایداری داده و مدیریت خطاها است.

انتخاب پارامترهای مناسب: اندازه سطل و نرخ پر شدن مجدد

انتخاب مقادیر مناسب برای اندازه سطل و نرخ پر شدن مجدد برای محدودسازی مؤثر نرخ درخواست بسیار مهم است. مقادیر بهینه به API خاص، موارد استفاده مورد نظر آن و سطح حفاظت دلخواه بستگی دارد.

• اندازه سطل: اندازه سطل بزرگتر، ظرفیت انفجاری بیشتری را فراهم می‌کند. این می‌تواند برای APIهایی که با افزایش‌های ناگهانی ترافیک مواجه می‌شوند یا جایی که کاربران به طور قانونی نیاز به ارسال یک سری درخواست‌های سریع دارند، مفید باشد. با این حال، یک سطل بسیار بزرگ ممکن است با اجازه دادن به دوره‌های طولانی استفاده با حجم بالا، هدف محدودسازی نرخ را تضعیف کند. هنگام تعیین اندازه سطل، الگوهای انفجاری معمول کاربران خود را در نظر بگیرید. برای مثال، یک API ویرایش عکس ممکن است به سطل بزرگتری نیاز داشته باشد تا به کاربران اجازه دهد یک دسته از تصاویر را به سرعت آپلود کنند.
• نرخ پر شدن مجدد: نرخ پر شدن مجدد، نرخ متوسط درخواست‌های مجاز را تعیین می‌کند. نرخ بالاتر اجازه درخواست‌های بیشتری در واحد زمان را می‌دهد، در حالی که نرخ پایین‌تر محدودکننده‌تر است. نرخ پر شدن مجدد باید بر اساس ظرفیت API و سطح انصاف مورد نظر بین کاربران انتخاب شود. اگر API شما منابع زیادی مصرف می‌کند، نرخ پر شدن مجدد پایین‌تری را انتخاب خواهید کرد. همچنین سطوح مختلف کاربری را در نظر بگیرید؛ کاربران ویژه ممکن است نرخ پر شدن مجدد بالاتری نسبت به کاربران رایگان دریافت کنند.

سناریوهای نمونه:

• API عمومی برای یک پلتفرم رسانه اجتماعی: یک سطل با اندازه کوچک (مثلاً ۱۰-۲۰ درخواست) و نرخ پر شدن مجدد متوسط (مثلاً ۲-۵ درخواست در ثانیه) ممکن است برای جلوگیری از سوءاستفاده و اطمینان از دسترسی منصفانه برای همه کاربران مناسب باشد.
• API داخلی برای ارتباطات میکروسرویس‌ها: یک سطل با اندازه بزرگتر (مثلاً ۵۰-۱۰۰ درخواست) و نرخ پر شدن مجدد بالاتر (مثلاً ۱۰-۲۰ درخواست در ثانیه) ممکن است مناسب باشد، با این فرض که شبکه داخلی نسبتاً قابل اعتماد است و میکروسرویس‌ها ظرفیت کافی دارند.
• API برای یک درگاه پرداخت: یک سطل با اندازه کوچکتر (مثلاً ۵-۱۰ درخواست) و نرخ پر شدن مجدد پایین‌تر (مثلاً ۱-۲ درخواست در ثانیه) برای محافظت در برابر تقلب و جلوگیری از تراکنش‌های غیرمجاز ضروری است.

رویکرد تکراری: با مقادیر اولیه معقول برای اندازه سطل و نرخ پر شدن مجدد شروع کنید و سپس عملکرد و الگوهای استفاده API را نظارت کنید. پارامترها را در صورت لزوم بر اساس داده‌های واقعی و بازخوردها تنظیم کنید.

ذخیره‌سازی وضعیت سطل

الگوریتم سطل توکن نیازمند ذخیره‌سازی دائمی وضعیت هر سطل (تعداد توکن‌ها و آخرین برچسب زمانی پر شدن) است. انتخاب مکانیزم ذخیره‌سازی مناسب برای عملکرد و مقیاس‌پذیری بسیار مهم است.

گزینه‌های رایج ذخیره‌سازی:

• حافظه پنهان درون-حافظه (مانند Redis, Memcached): سریع‌ترین عملکرد را ارائه می‌دهد، زیرا داده‌ها در حافظه ذخیره می‌شوند. برای APIهای با ترافیک بالا که تأخیر کم در آنها حیاتی است، مناسب است. با این حال، در صورت راه‌اندازی مجدد سرور حافظه پنهان، داده‌ها از بین می‌روند، بنابراین استفاده از مکانیزم‌های تکثیر یا پایداری را در نظر بگیرید.
• پایگاه داده رابطه‌ای (مانند PostgreSQL, MySQL): دوام و سازگاری داده‌ها را فراهم می‌کند. برای APIهایی که یکپارچگی داده‌ها در آنها از اهمیت بالایی برخوردار است، مناسب است. با این حال، عملیات پایگاه داده می‌تواند کندتر از عملیات حافظه پنهان درون-حافظه باشد، بنابراین پرس‌وجوها را بهینه‌سازی کرده و در صورت امکان از لایه‌های کش استفاده کنید.
• پایگاه داده NoSQL (مانند Cassandra, MongoDB): مقیاس‌پذیری و انعطاف‌پذیری را ارائه می‌دهد. برای APIهایی با حجم درخواست بسیار بالا یا جایی که شمای داده در حال تحول است، مناسب است.

ملاحظات:

• عملکرد: مکانیزم ذخیره‌سازی را انتخاب کنید که بتواند بار خواندن و نوشتن مورد انتظار را با تأخیر کم مدیریت کند.
• مقیاس‌پذیری: اطمینان حاصل کنید که مکانیزم ذخیره‌سازی می‌تواند به صورت افقی برای تطبیق با افزایش ترافیک مقیاس‌پذیر باشد.
• دوام: پیامدهای از دست دادن داده‌ها در گزینه‌های مختلف ذخیره‌سازی را در نظر بگیرید.
• هزینه: هزینه راه‌حل‌های مختلف ذخیره‌سازی را ارزیابی کنید.

مدیریت رویدادهای عبور از حد مجاز نرخ

هنگامی که یک کلاینت از حد مجاز نرخ فراتر می‌رود، مهم است که این رویداد را به شیوه‌ای مناسب مدیریت کرده و بازخورد آموزنده‌ای ارائه دهید.

بهترین شیوه‌ها:

• کد وضعیت HTTP: کد وضعیت استاندارد HTTP 429 Too Many Requests را بازگردانید.
• هدر Retry-After: هدر `Retry-After` را در پاسخ بگنجانید که تعداد ثانیه‌هایی را که کلاینت باید قبل از ارسال درخواست دیگر منتظر بماند، نشان می‌دهد. این به کلاینت‌ها کمک می‌کند تا از ارسال مکرر درخواست و تحت فشار قرار دادن API خودداری کنند.
• پیام خطای آموزنده: یک پیام خطای واضح و مختصر ارائه دهید که توضیح دهد حد مجاز نرخ درخواست رد شده است و نحوه حل مشکل را پیشنهاد دهد (مثلاً، قبل از تلاش مجدد صبر کنید).
• ثبت وقایع و نظارت: رویدادهای عبور از حد مجاز نرخ را برای نظارت و تحلیل ثبت کنید. این می‌تواند به شناسایی سوءاستفاده‌های احتمالی یا کلاینت‌های با پیکربندی نادرست کمک کند.

پاسخ نمونه:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 60

{
  "error": "Rate limit exceeded. Please wait 60 seconds before retrying."
}

ملاحظات پیشرفته

فراتر از پیاده‌سازی پایه، چندین ملاحظه پیشرفته می‌تواند اثربخشی و انعطاف‌پذیری محدودسازی نرخ درخواست API را بیشتر بهبود بخشد.

• محدودسازی نرخ لایه‌ای: محدودیت‌های نرخ متفاوتی برای سطوح مختلف کاربران (مثلاً رایگان، پایه، ویژه) پیاده‌سازی کنید. این به شما امکان می‌دهد سطوح مختلفی از خدمات را بر اساس طرح‌های اشتراک یا معیارهای دیگر ارائه دهید. اطلاعات سطح کاربر را در کنار سطل ذخیره کنید تا محدودیت‌های نرخ صحیح اعمال شود.
• محدودسازی نرخ پویا: محدودیت‌های نرخ را به صورت پویا بر اساس بار لحظه‌ای سیستم یا عوامل دیگر تنظیم کنید. برای مثال، می‌توانید نرخ پر شدن مجدد را در ساعات اوج مصرف کاهش دهید تا از بار اضافی جلوگیری کنید. این نیازمند نظارت بر عملکرد سیستم و تنظیم محدودیت‌های نرخ بر اساس آن است.
• محدودسازی نرخ توزیع‌شده: در یک محیط توزیع‌شده با چندین سرور API، یک راه‌حل محدودسازی نرخ توزیع‌شده پیاده‌سازی کنید تا از محدودسازی نرخ ثابت در تمام سرورها اطمینان حاصل شود. از یک مکانیزم ذخیره‌سازی مشترک (مانند کلاستر Redis) و هشینگ سازگار برای توزیع سطل‌ها در سرورها استفاده کنید.
• محدودسازی نرخ دانه‌ای: نقاط پایانی یا منابع مختلف API را بر اساس پیچیدگی و مصرف منابعشان به طور متفاوت محدود کنید. برای مثال، یک نقطه پایانی ساده فقط-خواندنی ممکن است حد مجاز نرخ بالاتری نسبت به یک عملیات نوشتن پیچیده داشته باشد.
• محدودسازی نرخ مبتنی بر IP در مقابل مبتنی بر کاربر: معایب و مزایای بین محدودسازی نرخ بر اساس آدرس IP و محدودسازی نرخ بر اساس شناسه کاربر یا کلید API را در نظر بگیرید. محدودسازی مبتنی بر IP می‌تواند برای مسدود کردن ترافیک مخرب از منابع خاص مؤثر باشد، اما ممکن است بر کاربران قانونی که یک آدرس IP مشترک دارند (مثلاً کاربرانی که پشت یک دروازه NAT هستند) نیز تأثیر بگذارد. محدودسازی مبتنی بر کاربر کنترل دقیق‌تری بر استفاده کاربران فردی فراهم می‌کند. ترکیبی از هر دو ممکن است بهینه باشد.
• ادغام با دروازه API: از قابلیت‌های محدودسازی نرخ دروازه API خود (مانند Kong, Tyk, Apigee) برای ساده‌سازی پیاده‌سازی و مدیریت استفاده کنید. دروازه‌های API اغلب ویژگی‌های محدودسازی نرخ داخلی را ارائه می‌دهند و به شما امکان می‌دهند محدودیت‌های نرخ را از طریق یک رابط متمرکز پیکربندی کنید.

دیدگاه جهانی در مورد محدودسازی نرخ

هنگام طراحی و پیاده‌سازی محدودسازی نرخ API برای مخاطبان جهانی، موارد زیر را در نظر بگیرید:

• مناطق زمانی: هنگام تنظیم فواصل پر شدن مجدد، به مناطق زمانی مختلف توجه داشته باشید. برای سازگاری، از برچسب‌های زمانی UTC استفاده کنید.
• تأخیر شبکه: تأخیر شبکه می‌تواند در مناطق مختلف به طور قابل توجهی متفاوت باشد. هنگام تنظیم محدودیت‌های نرخ، تأخیر بالقوه را در نظر بگیرید تا به طور ناخواسته کاربران در مکان‌های دور را جریمه نکنید.
• مقررات منطقه‌ای: از هرگونه مقررات منطقه‌ای یا الزامات انطباقی که ممکن است بر استفاده از API تأثیر بگذارد، آگاه باشید. برای مثال، برخی مناطق ممکن است قوانین حریم خصوصی داده داشته باشند که میزان داده‌های قابل جمع‌آوری یا پردازش را محدود می‌کند.
• شبکه‌های تحویل محتوا (CDN): از CDNها برای توزیع محتوای API و کاهش تأخیر برای کاربران در مناطق مختلف استفاده کنید.
• زبان و محلی‌سازی: پیام‌های خطا و مستندات را به چندین زبان برای پاسخگویی به مخاطبان جهانی ارائه دهید.

نتیجه‌گیری

محدودسازی نرخ API یک عمل ضروری برای محافظت از APIها در برابر سوءاستفاده و تضمین پایداری و در دسترس بودن آنها است. الگوریتم سطل توکن یک راه‌حل انعطاف‌پذیر و مؤثر برای پیاده‌سازی محدودسازی نرخ در سناریوهای مختلف ارائه می‌دهد. با انتخاب دقیق اندازه سطل و نرخ پر شدن مجدد، ذخیره‌سازی کارآمد وضعیت سطل و مدیریت مناسب رویدادهای عبور از حد مجاز نرخ، می‌توانید یک سیستم محدودسازی نرخ قوی و مقیاس‌پذیر ایجاد کنید که از APIهای شما محافظت کرده و تجربه کاربری مثبتی را برای مخاطبان جهانی شما فراهم می‌کند. به یاد داشته باشید که به طور مداوم استفاده از API خود را نظارت کرده و پارامترهای محدودسازی نرخ خود را در صورت لزوم برای انطباق با الگوهای ترافیکی در حال تغییر و تهدیدات امنیتی تنظیم کنید.

با درک اصول و جزئیات پیاده‌سازی الگوریتم سطل توکن، می‌توانید به طور مؤثر از APIهای خود محافظت کرده و برنامه‌های کاربردی قابل اعتماد و مقیاس‌پذیری بسازید که به کاربران در سراسر جهان خدمت‌رسانی می‌کنند.